Integrated Development Environments (IDEs) are software tools that allow a developer (e.g., a web developer) to create web pages, websites, interactive applications, and the like for use by end users (e.g., visitors to websites). Various IDEs exist in the current marketplace, such as DREAMWEAVER™ and FLEX™, both available from MACROMEDIA INC. of San Francisco, Calif. DREAMWEAVER™ is an IDE that allows web developers to design Hypertext Markup Language (HTML) web pages in both a code editor and a graphical-based design time environment. DREAMWEAVER™ also allows the developer to design in other languages, such as, for example, ASP, CFML™, and the like. FLEX™ is a presentation layer server that has an IDE associated with it for creating Rich Internet Applications (RIAs), which are interactive, multimedia, applications, that may run on client-side players or containers, for example, MACROMEDIA INC.'s FLASH™ player. FLEX™ utilizes MACROMEDIA INC.'s MXML™, an Extensible Markup Language (XML)-based language, to describe RIAs. Much of a developer's job is to create user interfaces (UIs) for the applications that are easy to use and enhance a user's experience.
The rich interface screens defined with MXML™ often include container objects to hold visual objects that are rendered in the resulting interface screens. In other words, a container may be considered to be an organizational unit for automatically laying out the visual elements of a UI. Thus, while an end user usually will not see container objects themselves in the application, the container objects are present, organizing and laying out the visual elements. In an MXML™ IDE, example container constructs include an HBox, VBox, form, form item, panel, tile, grid, grid row or item, title window, control bar, HDividedBox, VDividedBox, application, and the like. Each of these constructs define containers which, for example, position content horizontally (e.g., an HBox) and/or vertically (e.g., a VBox). Containers for HTML applications include, for example, table, DIV, and the like.
An example of a container in use is illustrated in FIG. 1. FIG. 1 presents screen shot 100 of a design view of an example IDE. Container 101 is an HBox (i.e., horizontal box), which is a type of container that is used to align several objects horizontally in a UI. For example, a developer who is designing a UI for playing multimedia animation may desire to insert control button objects 102-105 into the UI to allow a user to control the playing of the content. In the design view of FIG. 1, a developer may drag buttons 102-105 to container 101 and drop them in, wherein container 101 automatically aligns them such that there is a substantially uniform space between each button 102-105 and between the buttons 102-105 and the borders of container 101.
When nesting multiple containers in a UI in order to achieve an overall layout, many developers encounter a problem. For example, a UI under development may have a horizontal box to lay objects out horizontally and one or more vertical boxes which lay objects out vertically, wherein the vertical boxes are placed inside the horizontal box such that the vertical boxes can be laid across horizontally. Several of these containers will have shared edges. For example, the left edge of a VBox that is inside an HBox is the same as the left edge of the HBox. If the developer desires to insert another VBox before the current left-most VBox, the shared edge will not allow access to the virtual space between the left-most VBox and the left edge of the HBox because the shared edge appears as a single edge, rather than two edges with a space between them.
A previous solution has been to create a viewing mode wherein each edge of all container objects is given a space buffer that allows a developer to select the space between objects for editing or modification. The viewing mode allows objects to be placed between what would otherwise be presented as shared edges. Embodiments including this previous solution are described in commonly-assigned U.S. patent application Ser. No. 10/927,963. A problem with such a solution is that the expanded edge view presented to the developer is not a What You See Is What You Get (WYSIWYG) view because it is not a true representation of the UI at runtime. Further, it can be a slow algorithm when it involves recomputing the size of the objects and the positions of the spaces between the edges every time a new object is added, resized, or moved.